Enhanced management of thread-local objects

ABSTRACT

A method, executed by a computer, includes receiving a request to instantiate an instance of a thread-local manager for a particular thread, instantiating the instance of the thread-local manager, and providing global visibility to the instance of the thread-local manager. The method further includes manipulating thread-local variables corresponding to the particular thread and removing all the thread-local variables when the particular thread completes a task. A computer system and computer program product corresponding to the above method are also disclosed herein.

The following disclosure(s) are submitted under 35 U.S.C. 102(b)(1)(A)as prior disclosures by, or on behalf of, a sole inventor of the presentapplication or a joint inventor of the present application:

-   -   (1) IBM CICS Transaction Server for z/OS, V5.3 open beta        offering delivers advances in service agility, operational        efficiency, and cloud enablement with DevOps, IBM, Feb. 17,        2015.

BACKGROUND

The present invention relates to software development, and moreparticularly to enhanced management of Java thread-local objects.

In the computer programming industry, a thread is a part of a runningcomputer program (e.g., a computer process or task) that can executeindependently of other parts of the computer program. A thread pool is agroup of pre-instantiated threads that are reused as tasks becomeavailable for execution. When the task completes, the thread is returnedto the thread pool and is available for use by another task. Multiplethreads can execute concurrently within a single computer process.Concurrently executing threads may share some resources, while requiringexclusive access to other resources.

A thread-local object is an object that is bound to a specific thread,meaning the object is accessible only to the thread for which it wascreated. A thread-local variable is a variable within a thread-localobject that can only be seen (i.e., accessed) by the thread that createdthe thread-local object.

SUMMARY

As disclosed herein a method, executed by a computer, includes receivinga request to instantiate an instance of a thread-local manager for aparticular thread, instantiating the instance of the thread-localmanager, and providing global visibility to the instance of thethread-local manager. The method further includes manipulatingthread-local variables corresponding to the particular thread andremoving all the thread-local variables when the particular threadcompletes a task. A computer system and computer program productcorresponding to the above method are also disclosed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram depicting a computing environment,in accordance with at least one embodiment of the present invention;

FIG. 2 is a flowchart depicting a thread-local management method, inaccordance with at least one embodiment of the present invention;

FIG. 3 depicts an example of a thread using an application extension tomanage thread-local variables, in accordance with at least oneembodiment of the present invention; and

FIG. 4 is a functional block diagram depicting various components of oneembodiment of a computer suitable for executing the methods disclosedherein.

DETAILED DESCRIPTION

In today's highly computerized society, computing devices are becomingfaster and more powerful. One measure of computer performance is theamount of work that a computer can do in a given period of time (i.e.,throughput). One approach to increasing throughput on a computing deviceis to support multi-threaded execution. When a computer application isrunning in a multi-threaded environment, extra care must be taken toassure that data owned by one thread is not accidentally exposed toanother thread executing on the same computing device.

To avoid the overhead associated with repeatedly creating threads, manycomputing environments provide a thread pool. A thread pool can be acollection of previously created threads that may be assigned to a taskor process (e.g., part of a computer program) that is ready to beexecuted. When the task completes, the thread is returned to the threadpool and becomes available to be used by another task.

The use of thread-local objects and variables is one technique ofassuring that data is only visible (i.e., accessible) to a particularthread. If a thread creates a thread-local object, the thread-localobject is bound to the thread and is accessible only to the thread forwhich it was created. A thread-local object may contain thread-localvariables that can only be seen (i.e., accessed) by the thread thatcreated the thread-local object.

After a task that is using a thread has completed, yet prior to thethread being returned to the thread pool, all thread-local variablesassociated with the thread must be deleted (e.g., removed) so that thenext task to use the thread will not have visibility to any data from atask that had previously used the thread. Software frameworks may imposevisibility restrictions during execution of a task, which may result inthe creation of thread-local variables that are not visible to otherportions of the task executing in the thread. Prior to returning thethread to the thread pool, all thread-local variables should be removed.However, if inaccessible thread-local variables exist, then it ispossible that a clean-up routine may not be able to remove anythread-local variables with restricted visibility.

It has been determined that using thread-local variables in conjunctionwith software frameworks that may impose visibility restrictions mayunintentionally expose data between tasks running on a computing device.The embodiments disclosed herein generally address the above-describedproblems.

The present invention will now be described in detail with reference tothe Figures. FIG. 1 is a functional block diagram depicting a computingenvironment 100, in accordance with an embodiment of the presentinvention. Computing environment 100 includes server 110 and client 120,which can include smart phones, tablets, desktop computers, laptopcomputers, specialized computer servers, or any other computer systems,known in the art, capable of communicating over network 190. In general,server 110 and client 120 are representative of any electronic devices,or combination of electronic devices, capable of executingmachine-readable program instructions, as described in greater detailwith regard to FIG. 4.

As depicted, server 110 includes an application extension 111, athread-local manager 112, a thread pool manager 114, a thread pool 115,a class manager 116 and persistent storage 118. Server 110 may be a webserver, an application server, or any computing device capable ofperforming multi-threaded processing. Thread pool manager 114 may beconfigured to manage a collection of previously created threads (e.g.,thread pool 115). Thread pool manager 114 may assign a thread fromthread pool 115 to a task that is ready to execute on server 110. Whenthe task has completed, thread pool manager 114 may assure that anythread-local variables are removed from the thread, and place the threadback in thread pool 115 to be assigned to another task.

Application extension 111 may be a supplementary routine that addscapabilities to an application. Application extension 111 includesthread-local manager 112. Thread-local manager 112 may be a singletonimplementation of a thread-local object corresponding to a particularthread in thread pool 115. A singleton is an instantiation of a classobject that is restricted, allowing the instance to create only oneobject of that class type. Additionally, thread-local manager 112 mayreside in a memory location that enables thread-local manager 112 tohave a global scope of visibility to all thread-local variables definedin the thread to which an instance of thread-local manager 112corresponds. As depicted, application extension 111 may include morethan one instance of thread-local manager 112, where each instance ofthread-local manager 112 is a singleton object corresponding to aparticular thread from thread pool 115.

Thread-local manager 112 may implement the same functionality andprovide the same capabilities (e.g., methods, interfaces, and the like)that are provided by the native thread-local class (e.g., a nativethread-local manager). Thread-local manager 112 may also provideadditional functionality. In some embodiments, thread-local manager 112implements a method that enables the removal of all thread-localvariables corresponding to the current thread. In other embodiments,thread-local manager 112 implements a method that lists all existingthread-local variables, enabling each to be removed individually.Objects to be stored as thread-local variables may be passed tothread-local manager 112 via an application programming interface (API),allowing thread-local manager 112 to globally manage all thread-localvariables associated with the currently running thread.

When a task is running in a thread from thread pool 115, the task mayrequire the services of a framework managed by a class manager (e.g.,class manager 116). Class manager 116 may be configured to control whichclasses are able to be loaded (i.e., visible) during the execution ofthe task. Although the depicted example shows a single instance of classmanager 116, there may be multiple occurrences of class manager 116representing different software frameworks (e.g., CICS®, WebSphere®,OSGi™, and the like).

Depending on the currently running task, class manager 116 may controlwhich version of a class library, runtime library, or the like isvisible to the task. In some embodiments, class manager 116 enables arunning task to load version 3.0 of a runtime library. In otherembodiments, class manager 116 enables a running task to load version3.1 of the runtime library. While running under class manager 116, thetask may be executing with restricted visibility. In some embodiments,class manager 116 uses application extension 111 and thread-localmanager 112 to manipulate thread-local variables corresponding to thecurrently running task and thread. Using thread-local manager 112 mayallow global visibility to thread-local variables that may otherwisehave been inaccessible to thread pool manager 114. Differing versions ofclass libraries, runtime libraries, and the like that may be referencedby class manager 116 may be stored in persistent storage 118.

When the task has completed, all thread-local variables are removed fromthe thread prior to returning the thread to thread pool 115. Due topossible visibility restrictions, for example restrictions correspondingto actions performed by class manager 116, thread pool manager 114 maynot have visibility to all thread-local variables that were created inthe thread while the task was running. Thread-local manager 112 iscreated in a memory location that enables thread-local manager 112 tohave a global scope of visibility of all thread-local variables definedin the thread. To assure that all thread-local variables are removedfrom the thread, thread-local manager 112 may be called to remove allthread-local variables from the thread. In some embodiments, the requestto remove all thread-local variables is initiated by thread pool manager114. In other embodiments, the request to remove all thread-localvariables is initiated by application extension 111. After thethread-local variables are removed, thread pool manager 114 may placethe thread back in thread pool 115.

Client 120 may be any client that communicates with server 110 overnetwork 190. Client 120 may wish to use services provided by server 110.In some embodiments, client 120 uses an online banking application thatis provided by server 110. In other embodiments, client 120 usescomputational applications to produce analytics reports of customerdemographic corresponding to a web application. In the depictedembodiment, server 110 and client 120 are separate computers. In otherembodiments, server 110 and client 120 coexist on a single computer.Server 110 and client 120 may be procured from a cloud environment.

Persistent storage 118 may be any non-volatile storage media known inthe art. For example, persistent storage 118 can be implemented with atape library, optical library, one or more independent hard disk drives,or multiple hard disk drives in a redundant array of independent disks(RAID). Similarly, data on persistent storage 118 may conform to anysuitable storage architecture known in the art, such as a file, arelational database, an object-oriented database, and/or one or moretables.

Server 110, client 120, and other electronic devices (not shown)communicate over network 190. Network 190 can be, for example, a localarea network (LAN), a wide area network (WAN) such as the Internet, or acombination of the two, and include wired, wireless, or fiber opticconnections. In general, network 190 can be any combination ofconnections and protocols that will support communications betweenserver 110 and client 120 in accordance with an embodiment of thepresent invention.

FIG. 2 is a flowchart depicting a thread-local management method 200, inaccordance with at least one embodiment of the present invention. Asdepicted, thread-local management method 200 includes receiving (210) arequest to instantiate a thread-local manger object, creating (220) athread-local manager object, providing (230) global visibility,manipulating (240) thread-local variables, and removing (250) allthread-local variables. Thread-local management method 200 enables atask to use thread-local variables on a thread from thread pool 115 andclean up all thread-local variables corresponding to the task prior toreturning the thread to thread pool 115. Cleaning up all thread-localvariables corresponding to the task may reduce the risk ofunintentionally exposing data between tasks using the same thread atdifferent times.

Receiving (210) a request to instantiate a thread-local manger objectmay include application extension 111 receiving from thread pool manager114 a request to instantiate an instance of thread-local manager 112 fora specific thread in thread pool 115. In some embodiments, thread poolmanager 114 populates thread pool 115, and thread pool manager 114requests an instance of thread-local manager 112 for each thread inthread pool 115. In another embodiment, a new thread is created for atask that is ready to run on server 110, and a processor on server 110requests an instance of thread-local manager 112 for the new thread.

Creating (220) a thread-local manager object may include applicationextension 111 instructing thread-local manager 112 to construct aninstance of itself. In some embodiments, thread-local manager 112constructs a singleton instance of itself and provides a reference tothe newly create instance to application extension 111. In otherembodiments, a singleton instance of thread-local manager 112 currentlyexists, and thread-local manager 112 provides a reference to the currentinstance to application extension 111. Application extension 111 mayprovide the reference to the thread-local manager object to therequester (e.g., thread pool manager 114).

Providing (230) global visibility may include application extension 111providing an application programming interface (API) to the singletonthread-local manager 112 instance corresponding to the currently runningthread. The API may expose, to the task currently running on the thread,standard thread-local functionality, as well as any additionalfunctionality implemented by thread-local manager 112. Additionally,application extension 111 may reside in a location that providesthread-local manager 112 global visibility to thread-local variablescorresponding to the thread for which thread-local manager 112 wascreated. Any task that creates thread-local variables may usethread-local manager 112 to manipulate the thread-local variables ratherthan using a native thread-local reference.

Manipulating (240) thread-local variables may include applicationextension 111 providing an instance of thread-local manager 112 thatcorresponds to a thread. Thread-local manager 112 may provide an APIthat enables the functionality required to manipulate thread-localvariables corresponding to the thread. Any task executing on the threadthat creates thread-local variables may use thread-local manager 112 tomanipulate the thread-local variables rather than using a nativethread-local reference. Manipulating thread-local variables may includecalling thread-local manager 112 to initialize a thread-local object toa specific state, add (e.g., create) a thread-local variable, set (e.g.,assign) a value to a thread-local variable, get (e.g., retrieve) a valuefrom a thread-local variable, and/or remove (e.g., delete) athread-local variable corresponding to the current thread.

Removing (250) all thread-local variables may include applicationextension 111 detecting that the task currently running on a thread hascompleted processing, and the current thread may be returned to a threadpool. To avoid unintentionally exposing data between tasks, all existingthread-local variables may be removed from the thread, prior to thethread being returned to thread pool 115 and assigned to another task.Thread-local manager 112 may provide a command, for example, theremoveAll( ) method, enabling the removal of all thread-local variablesusing a single command. In some embodiments, the active thread invokesthe removeAll( ) method corresponding to thread-local manager 112 toinstruct thread-local manager 112 to remove (e.g., delete) all existingthread-local variables remaining on the current thread. In otherembodiments, application extension 111 invokes the removeAll( ) methodcorresponding to thread-local manager 112 to instruct thread-localmanager 112 to delete all existing thread-local variables remaining onthe current thread. In another embodiment, thread pool manager 114invokes the removeAll( ) method corresponding to thread-local manager112 to instruct thread-local manager 112 to delete all existingthread-local variables remaining on the current thread. After allthread-local variables are removed from the thread, the thread may bereturned to thread pool 115.

FIG. 3 depicts an example 300 of a thread using an application extensionto manage thread-local variables, in accordance with an embodiment ofthe present invention. As depicted, example 300 includes a thread 310,an application programming interface (API) 320, and an applicationextension 111. In some embodiments, thread 310 is a thread dispatchedfrom a thread pool (e.g., thread pool 115) to run task 315. In anotherembodiment, thread 310 is a thread that has been newly created to runtask 315. At the time thread 310 is created, a singleton instance ofthread-local manager 112 is also created within application extension111. In some embodiments, thread 310 uses API 320 to instantiate aninstance of thread-local manager 112.

In the depicted example, application extension 111 and thread-localmanager 112 may reside in a portion of a server (e.g. server 110) thatprovides a global scope of visibility to all thread-local variablesdefined in thread 310 using API 320. Thread-local manager 112 implementsthe same functionality as is provided by the native thread-local class[e.g., methods such as init( ), add( ), set( ), get( ) and remove( )],and therefore can manipulate all thread-local variables corresponding tothread 310 via API 320. Thread-local manager 112 may also maintainstructures (e.g., hashmaps) and references identifying each thread-localvariable of which thread-local manager 112 is aware. Thread-localmanager 112 may also implement additional function, such as a clean upmethod (e.g., the removeAll( ) method) that removes all thread-localvariables defined in thread 310.

In one embodiment, when task 315 has completed processing, allthread-local variables are deleted before the thread is returned to athread pool. In some embodiments, thread 310 invokes, via API 320, themethod removeAll( ) corresponding to thread-local manager 112, andthread-local manager 112 deletes any remaining thread-local variablecorresponding to thread 310. In other embodiments, application extension111 detects that task 315 has completed, and invokes the removeAll( )method corresponding to thread-local manager 112 prior to returningthread 310 to the thread pool.

FIG. 4 depicts a functional block diagram of components of a computersystem 400, which is an example of systems such as server 110 and client120 within computing environment 100 of FIG. 1, in accordance with anembodiment of the present invention. It should be appreciated that FIG.4 provides only an illustration of one implementation and does not implyany limitations with regard to the environments in which differentembodiments can be implemented. Many modifications to the depictedenvironment can be made.

Server 110 and client 120 include processor(s) 404, cache 414, memory406, persistent storage 408, communications unit 410, input/output (I/O)interface(s) 412 and communications fabric 402. Communications fabric402 provides communications between cache 414, memory 406, persistentstorage 408, communications unit 410, and input/output (I/O)interface(s) 412. Communications fabric 402 can be implemented with anyarchitecture designed for passing data and/or control informationbetween processors (such as microprocessors, communications and networkprocessors, etc.), system memory, peripheral devices, and any otherhardware components within a system. For example, communications fabric402 can be implemented with one or more buses.

Memory 406 and persistent storage 408 are computer readable storagemedia. In this embodiment, memory 406 includes random access memory(RAM). In general, memory 406 can include any suitable volatile ornon-volatile computer readable storage media. Cache 414 is a fast memorythat enhances the performance of processor(s) 404 by holding recentlyaccessed data, and data near recently accessed data, from memory 406.

Program instructions and data used to practice embodiments of thepresent invention, e.g., thread-local management method 200 are storedin persistent storage 408 for execution and/or access by one or more ofthe respective processor(s) 404 via cache 414. In this embodiment,persistent storage 408 includes a magnetic hard disk drive.Alternatively, or in addition to a magnetic hard disk drive, persistentstorage 408 can include a solid-state hard drive, a semiconductorstorage device, a read-only memory (ROM), an erasable programmableread-only memory (EPROM), a flash memory, or any other computer readablestorage media that is capable of storing program instructions or digitalinformation.

The media used by persistent storage 408 may also be removable. Forexample, a removable hard drive may be used for persistent storage 408.Other examples include optical and magnetic disks, thumb drives, andsmart cards that are inserted into a drive for transfer onto anothercomputer readable storage medium that is also part of persistent storage408.

Communications unit 410, in these examples, provides for communicationswith other data processing systems or devices, including resources ofserver 110 and client 120. In these examples, communications unit 410includes one or more network interface cards. Communications unit 410may provide communications through the use of either or both physicaland wireless communications links. Program instructions and data used topractice embodiments of thread-local management method 200 may bedownloaded to persistent storage 408 through communications unit 410.

I/O interface(s) 412 allows for input and output of data with otherdevices that may be connected to each computer system. For example, I/Ointerface(s) 412 may provide a connection to external device(s) 416 suchas a keyboard, a keypad, a touch screen, a microphone, a digital camera,and/or some other suitable input device. External device(s) 416 can alsoinclude portable computer readable storage media such as, for example,thumb drives, portable optical or magnetic disks, and memory cards.Software and data used to practice embodiments of the present inventioncan be stored on such portable computer readable storage media and canbe loaded onto persistent storage 408 via I/O interface(s) 412. I/Ointerface(s) 412 also connect to a display 418.

Display 418 provides a mechanism to display data to a user and may be,for example, a computer monitor.

The programs described herein are identified based upon the applicationfor which they are implemented in a specific embodiment of theinvention. However, it should be appreciated that any particular programnomenclature herein is used merely for convenience, and thus theinvention should not be limited to use solely in any specificapplication identified and/or implied by such nomenclature.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

What is claimed is:
 1. A computer program product comprising: one ormore computer readable storage media and program instructions stored onthe one or more computer readable storage media, the programinstructions comprising instructions to: receive a request toinstantiate an instance of a thread-local manager for a particularthread-local variable of a particular thread, wherein the instance ofthe thread-local manager only has access to the particular thread-localvariable; instantiate the instance of the thread-local manager; provideglobal visibility to the instance of the thread-local manager, whereinthe global visibility enables the instance of the thread-local managerto manage all thread-local variables of the particular thread, whereinprior to providing the global visibility, all of the thread-localvariables other than the particular thread-local variable are restrictedto be managed by other corresponding instances of thread-local manager;call the instance of the thread-local manager to manipulate allthread-local variables corresponding to the particular thread; and senda single command to the instance of the thread-local manger to removeall the thread-local variables when the particular thread completes atask.
 2. The computer program product of claim 1, wherein the programinstructions comprise instructions to implement, by the instance of thethread-local manager, all capabilities corresponding to a nativethread-local manager.
 3. The computer program product of claim 1,wherein the program instructions comprise instructions to restrictinstantiation of the thread-local manager to a single instancecorresponding to the particular thread-local variable of the particularthread.
 4. The computer program product of claim 1, wherein theinstructions to manipulate the thread-local variables compriseinstructions for one or more of initializing, adding, setting, getting,and removing the thread-local variables.
 5. The computer program productof claim 1, wherein the program instructions comprise instructions toprovide, by the instance of the thread-local manager, a command toremove all of the thread-local variables.
 6. The computer programproduct of claim 1, wherein the task is part of a computer program thatis ready to run.
 7. A computer system comprising: one or more computerprocessors; one or more computer readable storage media; programinstructions stored on the computer readable storage media for executionby at least one of the computer processors, the program instructionscomprising instructions to: receive a request to instantiate an instanceof a thread-local manager for a particular thread-local variable of aparticular thread, wherein the instance of the thread-local manager onlyhas access to the particular thread-local variable; instantiate theinstance of the thread-local manager; provide global visibility to theinstance of the thread-local manager, wherein the global visibilityenables the instance of the thread-local manager to manage all ofthread-local variables of the particular thread, wherein prior toproviding the global visibility, all of the thread-local variables otherthan the particular thread-local variable are restricted to be managedby other corresponding instances of thread-local manager; call theinstance of the thread-local manager to manipulate all thread-localvariables corresponding to the particular thread; and send a singlecommand to the instance of the thread-local manger to remove all thethread-local variables when the particular thread completes a task. 8.The computer system of claim 7, wherein the program instructionscomprise instructions to implement, by the instance of the thread-localmanager, all capabilities corresponding to a native thread-localmanager.
 9. The computer system of claim 7, wherein the programinstructions comprise instructions to restrict instantiation of thethread-local manager to a single instance corresponding to theparticular thread-local variable of the particular thread.
 10. Thecomputer system of claim 7, wherein the instructions to manipulate thethread-local variables comprise instructions for one or more ofinitializing, adding, setting, getting, and removing the thread-localvariables.
 11. The computer system of claim 7, wherein the programinstructions comprise instructions to provide, by the instance of thethread-local manager, a command to remove all of the thread-localvariables.